Padroneggiare le Prestazioni Frontend: Un'Analisi Approfondita dell'API User Timing

Nel panorama digitale moderno, le prestazioni del frontend non sono un lusso; sono un requisito fondamentale per il successo. Per un pubblico globale, un sito web lento e poco reattivo può portare a frustrazione dell'utente, a un calo del coinvolgimento e a un impatto negativo diretto sui risultati di business. Abbiamo eccellenti metriche standardizzate come i Core Web Vitals (Largest Contentful Paint, First Input Delay, Cumulative Layout Shift) che ci forniscono una comprensione di base dell'esperienza utente. Tuttavia, queste metriche, sebbene cruciali, raccontano solo una parte della storia.

Che dire delle prestazioni delle funzionalità specifiche dell'applicazione? Quanto tempo impiegano i risultati di ricerca a comparire dopo che un utente ha digitato una query? Quanto tempo impiega il tuo complesso componente di visualizzazione dati a renderizzarsi dopo aver ricevuto i dati da un'API? In che modo una nuova funzionalità influisce sulla velocità delle transizioni di rotta della tua single-page application (SPA)? Le metriche standard non possono rispondere a queste domande granulari e critiche per il business. È qui che entra in gioco la User Timing API, che consente agli sviluppatori di creare misurazioni delle prestazioni personalizzate e ad alta precisione, su misura per le loro applicazioni uniche.

Questa guida completa ti guiderà attraverso tutto ciò che devi sapere per sfruttare la User Timing API, dai concetti di base di mark e measure alle tecniche avanzate che utilizzano il PerformanceObserver. Alla fine, sarai in grado di andare oltre le metriche generiche e iniziare a raccontare la storia unica delle prestazioni della tua applicazione.

Cos'è la Performance API? Un Contesto Più Ampio

Prima di immergerci nell'API User Timing, è importante capire che fa parte di una suite più ampia di strumenti noti collettivamente come Performance API. Questa API del browser fornisce accesso a dati di temporizzazione ad alta precisione relativi alla navigazione, al caricamento delle risorse e altro ancora. L'oggetto globale `window.performance` è il tuo punto di accesso a questo potente set di strumenti.

La Performance API è composta da diverse interfacce, tra cui:

• Navigation Timing: Fornisce informazioni dettagliate sulla tempistica del processo di navigazione del documento, come il tempo impiegato per le ricerche DNS, gli handshake TCP e la ricezione del primo byte.
• Resource Timing: Offre dati dettagliati sulla tempistica di rete per ogni risorsa caricata dalla pagina, incluse immagini, script e file CSS.
• Paint Timing: Espone le tempistiche per il First Paint e il First Contentful Paint.
• User Timing: Il focus del nostro articolo, che permette agli sviluppatori di creare i propri timestamp personalizzati (mark) e misurare la durata tra di essi (measure).

Queste API lavorano insieme per fornire una visione olistica delle prestazioni della tua applicazione. Il nostro obiettivo oggi è padroneggiare la parte relativa alla User Timing, che ci dà il potere di aggiungere i nostri checkpoint personalizzati a questa timeline delle prestazioni.

I Concetti Chiave: Mark e Measure

La User Timing API è ingannevolmente semplice e ruota attorno a due concetti fondamentali: mark e measure. Pensala come usare un cronometro. Premi un pulsante per segnare un tempo di inizio e lo premi di nuovo per segnare un tempo di fine. La durata tra queste due pressioni è la tua misurazione.

Creare i Performance Mark: `performance.mark()`

Un 'mark' è un timestamp nominativo ad alta risoluzione registrato in un punto specifico dell'esecuzione della tua applicazione. È come piantare una bandierina sulla tua timeline delle prestazioni. Puoi creare tutti i mark di cui hai bisogno per identificare i momenti chiave nel percorso di un utente o nel ciclo di vita di un componente.

La sintassi è semplice:

performance.mark(markName, [markOptions]);

• markName: Una stringa che rappresenta il nome univoco per il tuo mark. Scegli nomi descrittivi!
• markOptions (opzionale): Un oggetto che può contenere una proprietà detail per allegare metadati extra e una proprietà startTime per specificare un timestamp personalizzato.

Esempio di Base: Contrassegnare un Evento

Supponiamo di voler contrassegnare l'inizio di una chiamata a una funzione importante.

            
function processLargeDataset() {
  // Inserisci un marcatore subito prima che inizi il lavoro pesante
  performance.mark('processLargeDataset:start');

  // ... logica computazionale pesante ...

  console.log('Elaborazione del dataset completata.');

  // Inserisci un altro marcatore quando ha finito
  performance.mark('processLargeDataset:end');
}

processLargeDataset();

            

              
                Copy
              
            
          

In questo esempio, abbiamo creato due timestamp nella timeline delle prestazioni del browser: `processLargeDataset:start` e `processLargeDataset:end`. Al momento, sono solo punti nel tempo. Il loro vero potere si sblocca quando li usiamo per creare una misurazione (measure).

Aggiungere Contesto con la Proprietà `detail`

A volte, un timestamp da solo non è sufficiente. Potresti voler includere un contesto extra su ciò che stava accadendo in quel momento. La proprietà `detail` è perfetta per questo. Può contenere qualsiasi dato che possa essere clonato strutturalmente (come oggetti, array, stringhe, numeri).

Immagina di contrassegnare l'inizio del rendering di un componente e di voler sapere quanti elementi stava renderizzando.

            
function renderProductList(products) {
  const itemCount = products.length;

  performance.mark('ProductList:render:start', {
    detail: {
      itemCount: itemCount,
      source: 'initial-load'
    }
  });

  // ... logica di rendering del componente ...

  performance.mark('ProductList:render:end');
}

const sampleProducts = new Array(1000).fill(0);
renderProductList(sampleProducts);

            

              
                Copy
              
            
          

Questo contesto aggiuntivo è inestimabile quando si analizzano i dati sulle prestazioni in un secondo momento. Potresti, ad esempio, correlare i tempi di rendering con il numero di elementi per vedere se c'è una relazione lineare o esponenziale.

Creare le Performance Measure: `performance.measure()`

Una 'measure' cattura la durata tra due punti nel tempo. È il calcolo che ti dice "quanto tempo" ha impiegato qualcosa. Più comunemente, misurerai il tempo tra due dei tuoi mark personalizzati.

La sintassi ha alcune varianti:

performance.measure(measureName, startMarkOrOptions, [endMark]);

• measureName: Una stringa che rappresenta il nome univoco per la tua misurazione.
• startMarkOrOptions (opzionale): Una stringa con il nome del mark di inizio. Può anche essere un oggetto di opzioni con `start`, `end`, `duration` e `detail`.
• endMark (opzionale): Una stringa con il nome del mark di fine.

Esempio di Base: Misurare la Durata di una Funzione

Riprendiamo il nostro esempio `processLargeDataset` e misuriamo effettivamente quanto tempo ha impiegato.

            
function processLargeDataset() {
  performance.mark('processLargeDataset:start');

  // ... logica computazionale pesante ...

  performance.mark('processLargeDataset:end');

  // Ora, crea la misurazione
  performance.measure(
    'processLargeDataset:duration',
    'processLargeDataset:start',
    'processLargeDataset:end'
  );
}

processLargeDataset();

            

              
                Copy
              
            
          

Dopo l'esecuzione di questo codice, il buffer delle prestazioni del browser conterrà una nuova voce chiamata `processLargeDataset:duration`. Questa voce avrà una proprietà `duration` che contiene il tempo preciso, in millisecondi, trascorso tra il mark di inizio e quello di fine.

Scenari di Misurazione Avanzati

Il metodo `measure()` è molto flessibile. Non è sempre necessario fornire due mark.

• Dall'Inizio della Navigazione a un Mark: Puoi misurare il tempo dall'inizio della navigazione della pagina a uno dei tuoi mark personalizzati. Questo è incredibilmente utile per misurare cose come il "Time to Interactive Component".

              
    // Misura dall'inizio della navigazione fino a quando il componente principale è pronto
    performance.measure('timeToInteractiveHeader', 'navigationStart', 'headerComponent:ready');
    
              
  
                
                  Copy
                
              
            

• Da un Mark a Ora: Se ometti l'endMark, la misura verrà calcolata dal tuo startMark al tempo attuale.

              
    // Misura dal mark di inizio fino all'esecuzione di questa riga di codice
    performance.measure('timeSinceDataRequest', 'api:fetch:start');
    
              
  
                
                  Copy
                
              
            

• Usare l'Oggetto Opzioni: Puoi anche passare un oggetto di configurazione per definire la misura, il che è utile per aggiungere una proprietà `detail`.

              
    performance.measure('complexRender:duration', {
      start: 'complexRender:start',
      end: 'complexRender:end',
      detail: { renderType: 'canvas' }
    });
    
              
  
                
                  Copy
                
              
            

Accedere e Pulire le Voci di Performance

Creare mark e measure è solo metà del lavoro. Hai bisogno di un modo per recuperare questi dati per analizzarli. L'oggetto `performance` fornisce diversi metodi per questo.

• performance.getEntries(): Restituisce un array di tutte le voci di performance nel buffer (incluse le tempistiche delle risorse, di navigazione, ecc.).
• performance.getEntriesByType(type): Restituisce un array di voci di un tipo specifico. Userai più spesso `performance.getEntriesByType('mark')` e `performance.getEntriesByType('measure')`.
• performance.getEntriesByName(name, [type]): Restituisce un array di voci con un nome specifico (e, facoltativamente, un tipo specifico).

Esempio: Registrare le Misure nella Console

            
// Dopo aver eseguito i nostri esempi precedenti...

const allMeasures = performance.getEntriesByType('measure');
console.log(allMeasures);

// Un oggetto di una voce di misurazione assomiglia a questo:
// {
//   "name": "processLargeDataset:duration",
//   "entryType": "measure",
//   "startTime": 12345.67,
//   "duration": 150.89
// }

const specificMeasure = performance.getEntriesByName('processLargeDataset:duration');
console.log(`L'elaborazione ha richiesto: ${specificMeasure[0].duration}ms`);

            

              
                Copy
              
            
          

Importante: Pulire il Buffer delle Prestazioni

Il buffer delle prestazioni del browser non è infinito. Per prevenire perdite di memoria e mantenere le tue misurazioni pertinenti, è una best practice cancellare i mark e le measure che hai creato una volta che hai finito di usarli.

• performance.clearMarks([name]): Cancella tutti i mark, o solo quelli con il nome specificato.
• performance.clearMeasures([name]): Cancella tutte le measure, o solo quelle con il nome specificato.

Un pattern comune è recuperare i dati, elaborarli o inviarli, e poi cancellarli.

            
function analyzeAndClear() {
  const myMeasures = performance.getEntriesByName('processLargeDataset:duration');
  // Invia myMeasures a un servizio di analytics...
  sendToAnalytics(myMeasures);

  // Pulisci per liberare memoria
  performance.clearMarks('processLargeDataset:start');
  performance.clearMarks('processLargeDataset:end');
  performance.clearMeasures('processLargeDataset:duration');
}

            

              
                Copy
              
            
          

Casi d'Uso Pratici e Reali per la User Timing

Ora che abbiamo compreso i meccanismi, esploriamo come applicare la User Timing API per risolvere sfide di performance del mondo reale. Questi esempi sono agnostici rispetto al framework e possono essere adattati a qualsiasi stack frontend.

1. Misurare la Durata delle Chiamate API

Capire per quanto tempo la tua applicazione attende i dati è fondamentale. Puoi facilmente avvolgere la tua logica di recupero dati con mark e measure.

            
async function fetchUserData(userId) {
  const markStart = `api:getUser:${userId}:start`;
  const markEnd = `api:getUser:${userId}:end`;
  const measureName = `api:getUser:${userId}:duration`;

  performance.mark(markStart);

  try {
    const response = await fetch(`https://api.example.com/users/${userId}`);
    if (!response.ok) {
      throw new Error('La risposta di rete non era ok');
    }
    return await response.json();
  } catch (error) {
    console.error('Errore di fetch:', error);
    // Puoi anche aggiungere dettagli sugli errori!
    performance.mark(markEnd, { detail: { status: 'error', message: error.message } });
  } finally {
    // Assicurati che il mark di fine e la misura vengano sempre creati
    if (performance.getEntriesByName(markEnd).length === 0) {
        performance.mark(markEnd, { detail: { status: 'success' } });
    }
    performance.measure(measureName, markStart, markEnd);
  }
}

fetchUserData('123');

            

              
                Copy
              
            
          

Questo pattern fornisce tempistiche precise per ogni chiamata API, permettendoti di identificare gli endpoint lenti direttamente dai dati degli utenti reali.

2. Tracciare i Tempi di Rendering dei Componenti nelle SPA

Per framework come React, Vue o Angular, misurare il tempo necessario a un componente per montarsi e renderizzarsi è un caso d'uso primario. Questo aiuta a identificare componenti complessi che potrebbero rallentare la tua applicazione.

Esempio con Hook di React:

            
import React, { useLayoutEffect, useEffect, useRef } from 'react';

function MyHeavyComponent({ data }) {
  const componentId = useRef(`MyHeavyComponent-${Math.random()}`).current;
  const markStartName = `${componentId}:render:start`;
  const markEndName = `${componentId}:render:end`;
  const measureName = `${componentId}:render:duration`;

  // useLayoutEffect viene eseguito in modo sincrono dopo tutte le mutazioni del DOM.
  // È il posto perfetto per segnare l'inizio della misurazione del rendering.
  useLayoutEffect(() => {
    performance.mark(markStartName);
  }, []); // Esegui solo al montaggio iniziale

  // useEffect viene eseguito in modo asincrono dopo che il rendering è stato applicato allo schermo.
  // Questo è un buon posto per segnare la fine.
  useEffect(() => {
    performance.mark(markEndName);
    performance.measure(measureName, markStartName, markEndName);

    // Registra il risultato per dimostrazione
    const measure = performance.getEntriesByName(measureName)[0];
    if (measure) {
      console.log(`${measureName} ha impiegato ${measure.duration}ms`);
    }

    // Pulizia
    performance.clearMarks(markStartName);
    performance.clearMarks(markEndName);
    performance.clearMeasures(measureName);
  }, []); // Esegui solo al montaggio iniziale

  return (
    // ... JSX per il componente pesante ...
  );
}

            

              
                Copy
              
            
          

3. Quantificare i Percorsi Utente Critici

L'uso più impattante della User Timing è la misurazione delle interazioni utente multi-step che sono critiche per il tuo business. Questo trascende le semplici metriche tecniche e misura la velocità percepita delle funzionalità principali della tua applicazione.

Considera un processo di checkout in un e-commerce:

            
const checkoutButton = document.getElementById('checkout-btn');

checkoutButton.addEventListener('click', () => {
  // 1. L'utente clicca il pulsante 'checkout'
  performance.mark('checkout:journey:start');

  // ... codice per validare il carrello, navigare alla pagina di pagamento, ecc. ...
});

// Nella pagina di pagamento, dopo che il modulo di pagamento è stato renderizzato e interattivo
function onPaymentFormReady() {
  performance.mark('checkout:paymentForm:ready');
  performance.measure('checkout:timeToPaymentForm', 'checkout:journey:start', 'checkout:paymentForm:ready');
}

// Dopo che il pagamento è stato elaborato con successo e viene mostrata la schermata di conferma
function onPaymentSuccess() {
  performance.mark('checkout:journey:end');
  performance.measure('checkout:totalJourney:duration', 'checkout:journey:start', 'checkout:journey:end');

  // Ora hai due potenti metriche da analizzare e ottimizzare.
}

            

              
                Copy
              
            
          

4. A/B Testing dei Miglioramenti delle Prestazioni

Quando effettui il refactoring di una porzione di codice o introduci un nuovo algoritmo, come dimostri che è effettivamente più veloce per gli utenti reali? La User Timing fornisce dati oggettivi per l'A/B testing.

Immagina di avere due diversi algoritmi di ordinamento che vuoi testare:

            
function sortProducts(products, algorithmVersion) {
  const markStart = `sort:v${algorithmVersion}:start`;
  const markEnd = `sort:v${algorithmVersion}:end`;
  const measureName = `sort:v${algorithmVersion}:duration`;

  performance.mark(markStart);

  if (algorithmVersion === 'A') {
    // ... esegui il vecchio algoritmo di ordinamento ...
  } else {
    // ... esegui il nuovo algoritmo di ordinamento ottimizzato ...
  }

  performance.mark(markEnd);
  performance.measure(measureName, markStart, markEnd);
}

// In base a un flag di A/B testing, chiameresti l'uno o l'altro.
// Successivamente, nei tuoi analytics, puoi confrontare la durata media di
// 'sort:vA:duration' vs 'sort:vB:duration' per vedere quale è stato più veloce.

            

              
                Copy
              
            
          

Visualizzare e Analizzare le Tue Metriche Personalizzate

Creare metriche personalizzate è inutile se non analizzi i dati. Ci sono due approcci principali: localmente durante lo sviluppo e in forma aggregata in produzione.

Utilizzare gli Strumenti per Sviluppatori del Browser

I browser moderni come Chrome e Firefox hanno un eccellente supporto per la visualizzazione dei mark e delle measure della User Timing nei loro strumenti di profiling delle prestazioni.

1. Apri gli Strumenti per Sviluppatori del tuo browser (F12 o Ctrl+Shift+I).
2. Vai alla scheda Performance.
3. Inizia a registrare un profilo e poi esegui le azioni nella tua app che attivano i tuoi mark e measure personalizzati.
4. Interrompi la registrazione.

Nella vista della timeline, troverai una riga dedicata chiamata Timings. I tuoi mark personalizzati appariranno come linee verticali e le tue measure saranno visualizzate come barre colorate che ne mostrano la durata. Passandoci sopra con il mouse verranno rivelati i loro nomi e le tempistiche esatte. Questo è un modo incredibilmente potente per eseguire il debug dei problemi di prestazioni durante lo sviluppo.

Inviare i Dati a Servizi di Analytics e RUM

Per il monitoraggio in produzione, è necessario raccogliere questi dati dai tuoi utenti e inviarli a una posizione centrale per l'aggregazione e l'analisi. Questa è una parte fondamentale del Real User Monitoring (RUM).

Il flusso di lavoro generale è:

1. Raccogliere le misure di performance che ti interessano.
2. Formattarle in un payload adeguato (ad es. JSON).
3. Inviare il payload a un endpoint di analytics. Potrebbe trattarsi di un servizio di terze parti come Datadog, New Relic, Sentry o persino Google Analytics (tramite eventi personalizzati), o un backend personalizzato che controlli tu.

            
function sendPerformanceData() {
  // Ci interessano solo le nostre misure applicative personalizzate
  const appMeasures = performance.getEntriesByType('measure').filter(
    (entry) => entry.name.startsWith('app:') // Usa una convenzione di denominazione!
  );

  if (appMeasures.length > 0) {
    const payload = JSON.stringify(appMeasures.map(measure => ({
      name: measure.name,
      duration: measure.duration,
      startTime: measure.startTime,
      details: measure.detail, // Invia il nostro ricco contesto
      path: window.location.pathname // Aggiungi altro contesto
    })));

    // Usa navigator.sendBeacon per un invio di dati affidabile e non bloccante
    navigator.sendBeacon('https://analytics.example.com/performance', payload);

    // Pulisci le misure che sono state inviate
    appMeasures.forEach(measure => {
      performance.clearMeasures(measure.name);
      // Cancella anche i mark associati
    });
  }
}

// Chiama questa funzione in un momento appropriato, ad es. quando la pagina sta per essere chiusa
window.addEventListener('visibilitychange', () => {
  if (document.visibilityState === 'hidden') {
    sendPerformanceData();
  }
});

            

              
                Copy
              
            
          

Tecniche Avanzate e Best Practice

Per padroneggiare veramente la User Timing API, diamo un'occhiata ad alcune funzionalità avanzate e best practice che renderanno la tua strumentazione più robusta ed efficiente.

Usare `PerformanceObserver` per il Monitoraggio Asincrono

I metodi `getEntries*()` richiedono di interrogare manualmente il buffer delle prestazioni. Questo ha due svantaggi: potresti eseguire il controllo troppo tardi e perdere delle voci se il buffer si è riempito ed è stato svuotato, e l'interrogazione stessa può avere un costo minimo in termini di prestazioni. La soluzione moderna e preferita è il `PerformanceObserver`.

Un `PerformanceObserver` ti permette di iscriverti agli eventi delle voci di performance. La tua funzione di callback verrà invocata in modo asincrono ogni volta che vengono registrate nuove voci dei tipi che stai osservando.

            
// 1. Crea una funzione di callback per gestire le nuove voci
const observerCallback = (list) => {
  for (const entry of list.getEntries()) {
    console.log('Nuova misura osservata:', entry.name, entry.duration);
    // Qui puoi inviare immediatamente la voce al tuo servizio di analytics
    // senza bisogno di interrogare o aspettare.
  }
};

// 2. Crea l'istanza dell'osservatore
const observer = new PerformanceObserver(observerCallback);

// 3. Inizia a osservare i tipi di voce 'mark' e 'measure'
// L'opzione 'buffered: true' assicura di ricevere le voci create
// *prima* che l'osservatore fosse registrato.
observer.observe({ entryTypes: ['mark', 'measure'], buffered: true });

// Ora, ogni volta che performance.mark() o performance.measure() viene chiamato
// in qualsiasi punto della tua applicazione, observerCallback verrà attivato con la nuova voce.

// Per smettere di osservare più tardi:
// observer.disconnect();

            

              
                Copy
              
            
          

Usare `PerformanceObserver` è più efficiente, più affidabile e dovrebbe essere la tua scelta predefinita per la raccolta di dati sulle prestazioni in un ambiente di produzione.

Stabilire una Chiara Convenzione di Denominazione

Man mano che la tua applicazione cresce, accumulerai molte metriche personalizzate. Senza una convenzione di denominazione coerente, i tuoi dati diventeranno difficili da filtrare e analizzare. Adotta un pattern che fornisca contesto.

Una buona convenzione potrebbe essere: [appName]:[featureOrComponent]:[eventName]:[status]

• ecom:ProductGallery:render:start
• ecom:ProductGallery:render:end
• ecom:ProductGallery:render:duration
• admin:DataTable:fetchApi:start
• admin:DataTable:fetchApi:duration

Questa struttura rende banale filtrare per tutte le metriche relative a `ProductGallery` o trovare tutte le durate di `fetchApi` nell'intera applicazione.

Astrarre in un Servizio di Utilità

Per garantire coerenza e ridurre il codice ripetitivo, racchiudi le chiamate a `performance` nel tuo modulo o servizio di utilità. Questo rende anche facile abilitare o disabilitare il monitoraggio delle prestazioni in base all'ambiente.

            
// performance-service.js

const IS_PERFORMANCE_MONITORING_ENABLED = process.env.NODE_ENV === 'production' || window.location.search.includes('perf=true');

export const perfMark = (name, options) => {
  if (!IS_PERFORMANCE_MONITORING_ENABLED) return;
  performance.mark(name, options);
};

export const perfMeasure = (name, start, end) => {
  if (!IS_PERFORMANCE_MONITORING_ENABLED) return;
  performance.measure(name, start, end);
};

export const startJourney = (name) => {
  perfMark(`${name}:start`);
};

export const endJourney = (name) => {
  const startMark = `${name}:start`;
  const endMark = `${name}:end`;
  const measureName = `${name}:duration`;

  perfMark(endMark);
  perfMeasure(measureName, startMark, endMark);
  // Opzionalmente, cancella i mark qui
};

// Nel tuo componente:
// import { startJourney, endJourney } from './performance-service';
// startJourney('ecom:checkout');
// ...più tardi...
// endJourney('ecom:checkout');

            

              
                Copy
              
            
          

Conclusione: Assumere il Controllo della Storia delle Prestazioni della Tua Applicazione

Mentre le metriche standard come i Core Web Vitals forniscono un controllo essenziale sullo stato di salute del tuo sito web, non illuminano le prestazioni delle funzionalità e delle interazioni che rendono unica la tua applicazione. La User Timing API è il ponte che colma questa lacuna. Fornisce un meccanismo semplice ma profondamente potente per misurare ciò che conta veramente per i tuoi utenti e il tuo business.

Implementando mark e measure personalizzati, trasformi l'ottimizzazione delle prestazioni da un gioco di supposizioni a una scienza basata sui dati. Puoi individuare le funzioni, i componenti o i flussi utente esatti che causano colli di bottiglia, convalidare l'impatto dei tuoi sforzi di refactoring con numeri oggettivi e, in definitiva, costruire un'esperienza più veloce e piacevole per il tuo pubblico globale.

Inizia in piccolo. Identifica il singolo percorso utente più critico nella tua applicazione, che si tratti della ricerca di un prodotto, dell'invio di un modulo o del caricamento di una dashboard di dati. Strumentalo con `performance.mark()` e `performance.measure()`. Analizza i risultati nei tuoi strumenti per sviluppatori. Una volta che vedrai la chiarezza che fornisce, sarai in grado di raccontare la storia completa delle prestazioni della tua applicazione, una metrica personalizzata alla volta.